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) Procede et systeme de transaction par carte a puce. 

57) L'invention conceme les transactions utilisant les car- 
ter a puces. 

Pour permettre de securiser sirnplement des operations 
de rechargement de montants prepayes dans des cartes a 
memoire, rneme a partir de terminaux (10) disperses non 
relies a un serveur centra! (20), on propose selon l'inven- 
tion de memoriser dans la carte a memoire (40) le nombre 
d'opeYations de rechargement effectuees. Un compteur de 
nombre de rechargements est done prevu; ce compteur est 
increments a chaque rechargement mais n'est pas incre- 
ments lors des autres utilisations de la carte, et notamment 
lors de I'utilisation de celle-ci pour consommer des biens 
ou services. 

L'invention est particulierement applicable a la gestion 
collective de nombreux restaurants d'entreprise ayant cha- 
cun plusieurs terminaux de rechargement a la disposition 
des employes de I' en t rep rise. 
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PROCEDE ET SYSTEME DE TRANSACTION PAR CARTE A PUCE 



L 1 invention concerne les cartes a puces et les 
systemes de transaction utilisant ces cartes. Les puces 
de ces cartes peuvent etre des puces avec memoire seule 
ou bien des puces comportant une memoire et un 
microprocesseur. On peut meme envisager d 1 avoir au 
moins deux puces, une memoire et un microprocesseur , 
sur la meme carte. 

Un systeme de transaction avec carte a puce 
typique est le porte monnaie electronique qui 
fonctionne de la maniere suivante : une carte a puce 
d'un particulier peut etre rechargee aupres d'une 
institution bancaire pour contenir une nouvelle valeur 
fiduciaire remplagant des billets de banque, le compte 
en banque du particulier etant debite d'une valeur 
correspondante; cette carte peut etre utilisee pour un 
echange d' argent avec un tiers (un commergant par 
exemple) ayant une carte similaire : une partie de 
1' argent disponible dans la premiere carte est mise au 
credit de la deuxieme dont le solde est ainsi augmente; 
le solde de la premiere carte est diminue d'autant. 
Apres un certain nombre d* operations . de ce genre, la 
deuxieme carte peut etre d^chargee aupres d'une 
institution bancaire pour transferer le solde de la 
carte vers un compte du titulaire de cette carte, 

Un autre systeme de transaction peut consister a 
recharger des cartes periodiquement a des bornes de 
rechargement reparties dans une zone geographique, puis 
a consommer des biens ou des services a l'aide de la 
carte; le solde de la carte decroit au fur et a mesure 
de 1 'utilisation jusqu'a epuisement du montant 
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recharge. Le montant recharge periodiquement peut etre 
fixe ou variable. II peut etre le meme pour toute une 
population de titulaires de cartes , par exemple dans 
une application oH on recharge des cartes de restaurant 
5 d'entreprise en debut du mois avec un nombre de repas 
fixe ou une somme d' argent fixe. 

D'autres systemes de transaction situes dans 
1* esprit de 1* invention pourraient concerner uniquement 
des transferts d • informations sans transfert de valeur 

10 monetaire. 

Les systemes de transaction, aussi bien d 1 unites 
de valeur que d • informations, exigent en general des 
precautions contre les fraudes. Pour cela, on utilise 

des informations conf identielles , des codes secrets, 

15 des algorithmes de verification de codes secrets, des 
algorithmes de cryptage d • informations, etc. 

Dans la demande de brevet FR-A-2653648 du 
deposant, on a deer it des systemes de transaction 
securisee, pour des cartes a puces ne comportant pas 

2 0 necessairement de microprocesseur . Essentiellement , la 
carte est une carte a memoire dans laquelle la memoire 
non volatile comporte au moins quatre zones 
differentes. Une premiere zone est reservee a des 
donnees d 1 identification de la carte (il n'y a en 

2 5 principe pas deux cartes ayant les memes donnees 

d • identification) . Une deuxieme zone est reservee a un 
solde de compte, qui diminue au fur et a mesure des 
utilisations. Une troisieme zone enregistre le nombre 
d 1 operations effectuees avec la carte. Et une quatrieme 

3 0 zone contient un certificat servant a verifier que le 

solde de la carte n'a pas ete modifie entre deux 
operations. Le certificat est place dans cette 
quatrieme zone par le lecteur de carte a 1 1 issue d'une 
transaction; il est calcule en faisant intervenir 
3 5 l'identite de la carte, le solde, et le nombre 
d • operations . Lors d'une utilisation suivante de la 



BNSDOCID: <FR 2716021 A1J_> 



2716021 



* 

J 



carte, le lecteur de carte verifie, a I'aide du merae 
algorithme, que le certificat est bien celui qui 
correspond a I'identite de la carte, au solde inscrit, 
et au nombre d 1 operations inscrit. Si ce n'est pas le 
5 cas, il prend des mesures en rapport avec la violation 
detectee; par exemple il interdit toute transaction, ou 
il conserve la carte, ou il transmet a un serveur 
central I'identite de la carte, etc, Cette quatri^me 
zone n'est indispensable que pour les cartes a memo ire. 

10 En effet, pour les cartes a memoires et a micro- 
processeur la securite est basee sur un certificat ou 
une signature emise par le terminal lors d'un debit ou 
d'un rechargement de la carte et qui permet a la carte 
de verifier l'origine du debit ou du rechargement. De 

15 meme la verification de cette zone certificat ne doit 
etre faite pas le terminal que pour les cartes a 
memoire car pour les cartes a micro-processeur la 
valeur du solde peut etre garantie par les mecanismes 
securitaires mis en place pour les debits et les 

2 0 rechargements. 

Bien que ce systeme soit tres simple et donne une 
bonne securite, on s'est apergu qu'il presentait des 
inconvenients pour certaines organisations de systemes 
de transaction. 

2 5 Par exemple, une organisation de transaction dans 

lequel ce mode de securite presente des inconvenients 
est la suivante : lorsque les utilisateurs doivent 
recharger leur carte aupres d'une institution, a partir 
de terminaux de rechargement repartis dans une zone 

3 0 geographique determinee et relies a un serveur central, 

les verifications sont faites par le serveur, et cela 
occupe beaucoup de temps de transmission en ligne si 
les utilisateurs sont nombreux. S*ils doivent tous 
recharger leurs cartes a peu pres au meme moment, par 
3 5 exemple en debut de mois, le probleme est encore plus 
delicat. II s'agit la d'un systeme de rechargement en 
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liaison directe ("on-line" en anglais) ; la carte, le 
terminal de rechargement et le serveur sont en effet 
relies entre eux pendant la transaction. 

On a done eu 1 • idee qu'on pourrait faire par 
5 avance les operations de verification dans le serveur, 
a partir des donnees provenant des operations 
precedemment effectuees par les cartes, et qu'on 
pourrait alors enregistrer dans les terminaux de 
rechargement tous les certificats des cartes qui 

10 peuvent se presenter. Les rechargements sont effectues 
en differe ("off-line" en anglais), le terminal n 1 etant 
pas en communication avec le lecteur au moment du 
rechargement. Mais cela impose de n'utiliser pour 

1-LaJ.qori thine de verification que des donnees connues 

15 par avance par le serveur. Or le nombre d f operations 
effectuees par la carte n'est pas connu, pas plus que 
le solde du compte. Par consequent, on ne peut pas 
appliquer telle quelle la procedure decrite dans * la 
demande de brevet precedemment citee. 

20 La presente invention propose une solution simple 

pour obtenir une securite satisf aisante pour beaucoup 
d 1 applications , sans empecher d'utiliser certaines 
organisations de transaction telle que celle decrite 
dans le paragraphe ci-dessus. 

25 Selon 1' invention, la carte comporte une zone 

d ' enregistrement non volatile contenant le nombre 
d 1 operations d'un type determine effectuees par le 
titulaire de la carte, ce nombre etant increments 
lorsqu'une operation de ce type est effectuee ma is 

3 0 n' etant pas increments lorsque la carte est utilisee 
pour des operations d'un autre type. Par exemple, si la 
carte doit effectuer des operations de debit et des 
operations de credit, un compteur specif ique pourra 
etre prevu pour les operations de credit seulement; ou 

3 5 encore pour les operations de debit seulement; ou 
encore on pourra avoir un compteur separe pour les 
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operations de debit et les operations de credit. Selon 
l 1 invention des secrets necessaires pour effectuer des 
debits seront ainsi differents de ceux necessaires pour 
effectuer des rechargements. 
5 Le compteur d f operations est irreversible, c'est- 

a-dire que la zone de memoire est organisee de manidre 
que le contenu lu ne puisse correspondre qu»a un nombre 
d 1 unites variant tou jours dans le meme sens. 

Le terminal de lecture de la carte etablira et 
10 enregistrera dans la carte un certificat resultant d'un 
algorithme de calcul utilisant d'une part les donnees 
d 1 identification de la carte et d * autre part au moins 
le contenu d'un compteur d' operations d'un type 
determine . 

15 L' application la plus simple, dans le cas oil les 

cartes sont rechargees a partir d'un terminal de 
rechargement , est la suivante : le rechargement n'est 
effectue que si le certificat inscrit dans la carte est 
compatible avec les donnees d • identification de la 

20 carte et avec le contenu non volatil du compteur 
d' operations de rechargement. On peut ainsi eviter une 
double operation de rechargement dans des organisations 
de rechargement en differe. Par exemple, lorsqu'un 
grand nombre de cartes doivent etre rechargees au cours 

2 5 d'une periode de temps aupres d'un terminal de 

rechargement quelconque, il faut eviter qu'une carte ne 
soit rechargee plusieurs fois dans des terminaux 
differents au cours de la meme periode. La presente 
invention apporte une solution a ce probleme. 
30 L'enregistrement du certificat dans la carte n'est 
necessaire que pour les cartes a memoire seule. Pour 
les cartes a micro-processeur, le certificat que 
transmet le terminal a la carte peut etre seulement 
controle par la carte elle-meme qui accepte ou refuse 

3 5 l'ordre en fonction de la veracite de ce certificat. 

Le procede de transaction selon 1 • invention 
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comporte done les operations suivantes : utilisation de 
la carte et incrementation irreversible d'un compteur 
d 1 operations, present dans la carte, uniquement 
lorsqu'une operation d'un type determine est effectuee 
5 au cours d'une utilisation, le compteur n'etant pas 
increments pour des operations d'un autre type, 

De preference, !• operation qui donne lieu a 
incrementation du compteur d f operations est une 
operation de rechargement d'une valeur consommable dans 
10 une memoire de la carte. 

On peut prevoir qu'il y a plusieurs compteurs, 
chacun etant incremente pour un type d' operation 
respectif. On peut meme prevoir qu'un compteur est 

incremente— pour^—chacune des- opexat±ons_appar_tena nt a un 

15 groupe de plusieurs types d' operations differents, ce 
compteur n'etant pas incremente pour d 1 autres 
operations possibles mais n * appartenant pas a ce 
groupe . 

Dans une mise en oeuvre detaillee possible, dans 
20 laquelle les cartes sont rechargeables dans des 
terminaux disperses susceptibles de recevoir des 
donnees d'un serveur, 1' invention peut comporter les 
etapes suivantes : 

- chargement, depuis un serveur vers des terminaux 

2 5 de rechargement de cartes, de donnees permettant aux 

terminaux de verifier le droit d'une carte a etre 
rechargee ; 

- introduction d'une carte dans un terminal de 
rechargement quelconque ; 

3 0 - lecture par le terminal de donnees 

d ' identif ication de la carte pr^sentes dans la carte 

- lecture par le terminal d'un compteur 
d' operations de rechargement present dans la carte 

- lecture et verification par le terminal d'un 
35 certificat d 1 authenticity present dans la carte, ce 

certificat faisant intervenir les donnees 
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d ■ identification et le contenu du compteur; le compteur 
d' operations de rechargement etant incremente aprds 
chaque operation de rechargement et n 1 etant pas 
incremente pour des operations autres qu'un 
5 rechargement . 

Ces operations selon I 1 invention permettent 
d'etablir 1 ' habilitation de la carte. 

La verification de la zone certificat ne doit etre 
faite par le terminal que pour les cartes a memo ire 
10 seule, car pour les cartes a micro-processeur la valeur 
du solde peut etre garantie par les mecanismes 
securitaires mis en place pour les debits et les 
rechargements . 

Apres ces operations, le rechargement peut etre 
15 effectue. 

Dans cette definition, on notera que le serveur 
n'est pas forcement physiquement relie aux terminaux : 
une disquette de memoire magnetique produite par le 
serveur peut etre transportee dans les terminaux pour y 
20 placer les donnees necessaires aux verifications 
d 'habilitation des cartes. 

D r autres caracteristiques et avantages de 
1' invention apparaitront a la lecture de la description 
detaillee qui suit et qui est faite en reference aux 
25 dessins annexes dans lesquels : 

- la figure 1 represente 1 1 organisation genera le 
d'une application dans laquelle la presente invention 
peut etre avantageusement mise en oeuvre; 

- la figure 2 represente schematiquement diverses 
30 zones de memoire non-volatile d'une carte utilisable 

dans le procede selon 1' invention; 

- la figure 3 represente un organ igramme general 
des etapes d'un procede de rechargement de carte selon 
1 * invention . 

35 L f invention sera decrite en detail a propos d'un 

exemple d • application particulier (fig 1) qui est la 
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gestion des cartes de restaurant d 1 entreprises . Les 
titulaires des cartes sont des employes appartenant a 
des entreprises ou organismes differents, la gestion 
des cartes etant assuree par un prestataire de service 
5 (entreprise de restauration) . 

On suppose que tous les employes d'une entreprise 
possedent une carte de type M porte-monnaie 
electronique" permettant d'acceder au restaurant 
d 1 entreprise, le financement de cette carte 6tant pris 

10 en charge par le titulaire et/ou par 1 1 entreprise. 

Chaque mois, apres avoir paye au prestataire de 
service une somme correspondant aux cartes a recharger, 
!• entreprise reqroit du prestataire un fichier contenant 

tous les ordres de rechargement de ses employes. Ce 

15 fichier est destine a etre utilise par un ou plusieurs 
terminaux de rechargement 10 places dans 1 •entreprise • 
Si l 1 entreprise occupe une surface importante plusieurs 
terminaux seront repartis sur cette surface afin que 
tous les employes puissent facilement acceder a un 

20 terminal le jour ou ils doivent effectuer le 
rechargement de leur carte. 

Le fichier de rechargement peut etre transmis par 
le prestataire de service de differentes manieres; par 
exemple la transmission peut se faire par une liaison 

25 directe ou une liaison par modem si les terminaux sont 
relies directement ou par des lignes telephoniques a un 
serveur 2 0 du prestataire; ou au contraire, la 

transmission peut se faire par transport physique d'une 
disquette magnetique 30 ou de tout autre moyen de 

30 memoire non volatile (carte a puce, etc.) si les 
terminaux ne sont pas relies au serveur 20 du 
prestataire . 

Le fichier transmis par le prestataire est 
installe dans les terminaux de rechargement de 
3 5 1 1 entreprise • Le fichier de rechargement transmis aux 
terminaux peut etre le meme pour tous les terminaux. II 
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est alors duplique dans tous ces terminaux. 

Ces terminaux peuvent etre de simples ordinateurs 
personnels (PC) avec un lecteur de cartes a puce. 

Les employes desirant recharger leur carte 4 0 
5 peuvent se rendre aupres d'un terminal quelconque 
(1* invention permet d f eviter d'obliger un titulaire de 
carte a utiliser un terminal precis) . La carte est 
introduite dans le lecteur de cartes du terminal 10 et 
est automatiqueinent rechargee du montant prevu it 
10 Pavance par le prestataire de service, montant qui 
peut etre constant pour tous les titulaires ou au 
contraire individualise pour chacun. Le montant peut 
egalement varier en fonction de la date du 
rechargement . 

15 Le prestataire de service gere les montants qui 

doivent etre recharges dans chaque carte. 

La periode pendant laquelle peut s'effectuer le 
rechargement peut etre fixe ou variable. Par exemple on 
peut prevoir que le rechargement doit etre effectu£ le 
20 premier de chaque mois. 

La carte ainsi rechargee peut etre utilisee un 
certain nombre de fois entre deux rechargements pour 
consommer les services offerts par le restaurant 
d f entreprise f selon des modalites definies par le 
25 prestataire de service. 

La description de 1* exemple d 1 application qui 
precede permet de mieux comprendre le f onctionnement de 
1 • invention. 

Dans le procede et le systeme de transaction selon 
30 1' invention, la carte comporte des moyens pour compter 
(et memoriser de maniere non-volatile) le nombre 
d 1 operations de rechargement effectuees, ce compteur 
n'etant pas increments lors des autres utilisations de 
la carte, c'est-a-dire en particulier lors de 
35 1 'utilisation de la carte pour consommer des services. 

On remarquera que dans d 1 autres applications, le 
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compteur pourrait bien stir memoriser un autre type 
d' operations que le rechargement: par exemple des 
operations de visualisation d'etat du compte. 

La figure 2 represente schema tiquexnent differentes 
5 zones de memoire non volatile qui peuvent etre prevues 
dans la carte pour mettre en oeuvre !• invention. Ces 
zones ont ete representees comine differentes parti s 
d'une meme memoire non volatile MNV; mais bien entendu, 
ces zones de memoire peuvent etre physiquement separees 

10 les unes des autres, c f est-&-dire qu'elles ne sont pas 
forcement toutes adressables par un meme decodeur 
d'adresse unique. II faut bien comprendre en effet que 
ces differentes zones ne sont pas forcement accessibles 

de la meme maniere. Par exemp le certaines zongg, telles 

15 que celle qui contient une donnee d 1 identification de 
la carte sont completement inaccessibles en ecriture, 
alors que d 1 autres (celle qui contient un solde par 
exemple) peuvent etre accedees en ecriture. 

Sur la figure 2, on a represente a titre d' exemple 

20 une premiere zone Zl qui contient les donnees 
d' identification (PIN: Personal Identification Number) 
de la carte; ces donnees permettent d 1 identifier de 
maniere univoque la carte, c'est-a-dire qu'il n*y a pas 
deux cartes ayant les memes donnees d • identification. 

25 Une autre zone Z2 sert de compteur d f operations de 

rechargement de la carte et contient un nombre NBR 
representant done le nombre de rechargements deja 
effectues. Cette zone est incrementee a chaque 
operation de rechargement mais n'est pas incrementee 

30 lorsque la carte est utilisee pour d 1 autres operations. 

Une troisieme zone Z3 contient un certificat CRT 
qui est une donnee resultant d'un algorithme de 
securite; ce certificat permet de verifier qu f il n»y a 
pas d • utilisation non autorisee de la carte, et en 

3 5 particulier qu'il n*y a pas eu des rechargements non 
autorises. Cette zone Z3 n'est utile que pour les 
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cartes a memoire. En effet pour les cartes a micro- 
processeur la securite est basee sur un certificat ou 
une signature emis par le terminal a la carte lors d"un 
debit ou d'un rechargement et qui permet a la carte de 
verifier l'origine du debit ou du rechargement. 

Une quatrieme zone Z4 peut contenir un solde 
variable SLD, rerais a jour au moment du rechargement et 
diminuant progress ivement au fur et a mesure de la 
consommation de biens ou services a l'aide de la carte. 

Une cinquieme zone 25 peut contenir un nombre NOP 
d' operations effectuees avec la carte; ce nombre inclut 
a la fois les operations de rechargement et les 
operations de consommation de biens ou services. Mais 
la zone Z5 pourrait aussi contenir un nombre NCS 
representant seulement les operations de consommation 
de biens ou services, cette zone n'etant pas 
incrementee lors des operations de rechargement. En 
variante, on peut prevoir une zone Z5 pour le nombre 
NOP et une zone Z6 differente pour le nombre NCS. 

Enfin, d'autres zones, referencees globalement 
sous la reference Z7 peuvent etre prevues dans la 
memo ire MNV. 

Pour assurer la securite du rechargement, on va 
s' arranger : 

- d'une part pour que seuls soient possibles les 
rechargements de carte de titulaires autorises (le 
prestataire definit les titulaires autorises, reperes 
par le numero d • identif ication personnelle PIN de la 
carte) ; 

- d 1 autre part pour qu'il ne soit pas possible de 
faire un double rechargement d'une meme carte en 
profitant de la multiplicity de terminaux simultanement 
prepares pour des rechargements de tous les titulaires. 

Pour cela, on utilise a la fois le compteur 
d* operations de rechargement present dans la carte et 
le numero d ' identif ication de la carte, egalement 
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present dans la carte. Ces deux donnees permettent 
d'etablir un certificat, lui aussi plac' dans la carte, 
ou au moins controlable par la carte, et ce certificat 
n'est valable que pour une carte determinee avec un 
5 etat de compteur determine. 

L'etat NBR du compteur de rechargements (Z2) varie 
de maniere irreversible, c 1 est-^-dire que le contenu du 
compteur non volatil (ou le contenu de la zone de 
memoire qui constitue ce compteur) repr^sente un nombre 

10 entier variant tou jours dans le mdme sens a chaque 
nouvelle operation de rechargement . 

Le protocole de communication entre le terminal de 
rechargement et la carte peut etre celui qui va dtre 

deer it ci-dessous? les etapes so n t ra ppelees sur 

15 1 ' organ igramme de la figure 3 : 

- le titulaire de la carte introduit sa carte dans 

le terminal de rechargement; les operations qui suivent * 
peuvent se derouler automat iquement sans intervention 
du titulaire, mais on comprendra que dans certains cas 

2 0 on peut preferer une intervention du titulaire 

(notamment si le terminal est un PC pouvant servir a 
d 1 autres usages ) . 

- le terminal lit dans la zone Zl le numero 
d ' identification de la carte (PIN); 

25 - le terminal recherche, dans le fichier de 

rechargement transmis par le prestataire, un numero 
correspondant , pour s' assurer que le titulaire fait 
partie des titulaires a priori habilites; 

- le terminal lit dans la carte le contenu NBR du 

3 0 compteur de nombre de rechargements (Z2); 

- le terminal lit dans la carte le contenu CRT de 
la zone de certificat Z3 uniquement si le certificat a 
ete enregistre dans la carte, ce qui n'est necessaire 
que pour les cartes a memoire; le certificat contenu 

3 5 dans cette zone y a ete place lors d'une operation de 
rechargement precedente; 
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- le terminal lit dans le fichier de rechargement 
on calcule, par un algorithme faisant intervenir le 
numero d • identification PIN et le contenu NBR du 
compteur de rechargements, le certificat theorique qui 

5 devrait correspondre au numero d f identification lu et 
au nombre de rechargements lu; dans une variante 
preferee d' execution, le terminal ne poss&de pas 
1' algorithme de calcul et il se contente de prelever, 
dans le fichier de rechargement etabli par le serveur, 

10 un certificat correspondant a la carte et au numero 
d'ordre de l 1 operation de rechargement; l'avantage de 
cette maniere de proceder est que l 1 algorithme est 
alors present uniquement dans le serveur et n'a pas 
besoin d'etre present dans les terminaux; ceux-ci ne 

15 peuvent etre alors detournes par fabrication du fichier 
de rechargement qui leur est transmis. 

le terminal verifie la compatibility du 
certificat lu et du certificat calcule ou preleve dans 
le fichier, et autorise ou non les operations de 

20 rechargement qui suivent en fonction du resultat de la 
verification; en cas de non compatibilite, les mesures 
prises peuvent etre diverses, par exemple : re jet de la 
carte, messages d'erreur, demande de nouvelle 
tentative, confiscation de la carte au bout de 

25 plusieurs tentatives manquees, mise en memoire, dans un 
fichier des tentatives de fraude, du numero de la carte 
ayant donne lieu a ces echecs, etc. 

- pour les cartes a microprocesseur , le terminal 
envoie a la carte l'ordre avec le certificat de son 

30 fichier et la carte autorise ou refuse l'ordre en 
fonction de la veracite du certificat. Si la carte 
autorise l'ordre, de fagon automatique elle incremente 
son compteur de transaction* 

- en cas de succes de la verification, le terminal 
3 5 ou la carte effectuent le rechargement : c f est une 

remise a jour de la zone de memoire non volatile 24 
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representant un credit disponible (en somme d» argent, 
en unites de corapte, en nombre de repas, etc...); au 
besoin cette mise a jour s'effectue en cumulant les 
unites apportees au solde des unites presentes dans la 
carte. 

- le terminal increraente le contenu du compteur 
d' operations de rechargement Z2; cette incrementation 
peut aussi etre effectuee plus tard; 

- le terminal inscrit un nouveau certificat dans 
la zone de certificat Z3 de la carte; ce certificat est 
calcule par le terminal s'il possede 1 • algorithroe, ou 
preleve dans le fichier de rechargement si le terminal 
ne possede pas 1 1 algorithme; le calcul du certificat 
fait intervenir 1 1 identification de la carte, et le 

15 nouveau contenu du compteur d* operations de 
rechargement (ou 1'ancien contenu increments d'une 
unite) ; 

- dans une realisation possible, la carte possede 
l f algorithme de calcul du certificat et peut calculer 

20 et enregistrer le nouveau certificat et verifier que le 
nouveau certificat ecrit par le terminal correspond 
bien a celui qu'elle calcule; sinon, diverses mesures 
de protection peuvent etre prises, telles que par 
exemple !• absence d • incrementation du compteur. 

2 5 La procedure de rechargement se termine alors. La 

carte ayant subi avec succes la procedure de 
rechargement peut etre utilisee pour des operations de 
consommation de biens ou services (consommation de 
repas dans le restaurant d 1 entrepr ise) . 

30 Le terminal quant a lui inscrit dans le fichier de 

rechargement ou dans un autre fichier une information 
indiquant que pour cette carte le rechargement a ete 
effectue. Cette information sera transmise 

ulterieurement au serveur chez le prestataire de 

35 service. 

Si 1 • utilisateur se presente maintenant a un autre 
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terminal de rechargement, au cours de la meme periode 
de rechargement, avec sa carte deja rechargee, la 
procedure de rechargement ne pourra pas a nouveau se 
derouler norma lement puisque a la fois le contenu du 
5 compteur d 1 operations et le certificat auront change. 
L ' irreversibility du compteur empeche toute fraude : il 
n'est pas possible de remettre a sa valeur precedente 
le contenu de la zone 22 lorsqu'il a change. 

II peut arriver qu'un utilisateur n f ait pas 
10 recharge sa carte a la fin de la periode pendant 
laquelle le rechargement aura it dQ s'effectuer. Dans ce 
cas, les rechargements suivants deviennent difficiles a 
gerer. 

Pour que cette situation soit plus facilement 
15 geree, on peut prevoir que le fichier de rechargement 
transmis aux terminaux comporte plusieurs 

enregistrements pour chaque carte, correspondant l'un a 
1' operation de rechargement en cours, 1 1 autre aux 
dernieres operations de rechargement theoriques qui 
20 auraient du etre effectuees et qui en fait ne I'ont pas 
ete. Pour un numero de carte donne, on a done au moins 
un enregistrement comportant une information de contenu 
de compteur correspondant a l 1 operation theorique en 
cours, avec un certificat correspondant, mais aussi 

2 5 eventuellement , pour certaines cartes deux 

enregistrements (ou plus) avec un meme numero de carte, 
et plusieurs contenus de compteur successifs (autant 
que d' operations de rechargement non effectuees), et 
des certificats correspondants . 
30 Dans ce cas, le terminal recherche toujours 

1 " enregistrement correspondant au nombre de 
rechargements indique dans la carte. En effet, e'est le 
rechargement correspondant a ce nombre qui doit etre 
fait en premier, Ceux d'avant sont supposes faits 

3 5 puisque la carte a ete incrementee jusqu'a ce contenu; 

ceux d 1 apres ne doivent etre effectues qu'ensuite. La 
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procedure de rechargement peut alors etre effectuee 
normalement vis-a-vis de cet enregistrement. 
Lorsqv^elle est effectuee, le titulaire peut proceder a 
nouveau a un rechargement, par exemple le dernier s'il 
5 n ! y avait qu'un seul enregistrement de retard. Ce 
nouveau rechargement peut etre effectue dans le m&me 
terminal ou un autre, 

Dans ce qui precede, on a suppose que le numero 
d 1 identification de la carte et le contenu du compteur 

10 de rechargements servent directement a calculer le 
certificat d ' authenticity . Mais on peut prevoir aussi 
que ces elements peuvent servir a etablir des cles de 
cryptage des transmissions entre la carte et le 

terminal et non pas seulement le cert ificat. 

15 Les etapes principales decrites ci-dessus et 

rappelees a la figure 3 representent une procedure 
simple de transaction; il va de soi que des procedures 
plus complexes peuvent etre mises en oeuvre pour 
accroltre la securite; par exemple 1 • habilitat ion de la 

20 carte peut etre renforcee par une procedure de 
verification d'un code secret demand e par le terminal 
et introduit par 1 ' utilisateur sur un clavier du 
terminal de rechargement. 

Pour realiser un compteur irreversible a partir 

25 d'une zone de memoire Z2, il est classique maintenant 
d'utiliser des memoires non-volatiles dont les cellules 
peuvent etre programmees successivement les unes apres 
les autres, I'effacement etant impossible. La 
programmation peut etre effectuee sous la commande d'un 

3 0 microprocesseur lorsque la carte en comporte un, ou 
sous la commande de circuits simples lorsqu'il n'y a 
pas de microprocesseur. 

Enfin, on comprendra que si la carte comporte 
plusieurs compteurs pour des types d 1 operations 

35 differents, tels que ceux qui correspondent aux zones 
Z2 et Z6, les contenus de chacun de ces compteurs 
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peuvent servir a des procedures de verification pour 
les differents types d* operations effectuees avec la 
carte. 

On aura compris de l'exemple d 1 application 
detaille ci-dessus que 1 • invention est particulierement 
applicable a un systeme de gestion collective de 
nombreux restaurants d'entreprise ayant chacun 
plusieurs tenninaux de rechargement t la disposition 
des employes de 1 ' entreprise. Elle est en outre 
aisement transposable a n * importe quel autre type de 
services . 
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REVENDICATIONS 

1. Procede de transaction a partir d'une carte a 
memoire (40) comportant une memoire non volatile (MNV) , 
ce procede comportant 1 •utilisation de la carte et 
1 ' incrementation irreversible d 1 un compteur 

5 d' operations present dans la carte, caractSrisS en ce 
que le compteur (Z2) est increments uniquement 
lorsqu'une operation d'un type determine est effectuSe 
au cours d'une utilisation de la carte, le compteur 
n'etant pas increments pour des operations d'un autre 
10 type. 

2. Procede de transaction selon la revendication 
1-, caracterise en ce q ue 1 1 operation d'un type 

determine est une operation de rechargement d'une 
valeur consommable dans la memoire de la carte. 
15 3. Procede de transaction selon rune des 

revendications 1 et 2 , caracterise en ce que plusieurs 
compteurs (Z2, 26) sont prevus, chacun etant increments 
pour une operation d'un type respectif. 

4. Procede de transaction a partir d'une carte a 
20 memoire comportant une memoire non volatile, comportant 

1 'utilisation de la carte et 1 • incrementation 
irreversible d'un compteur d » operations, caracterise en 
ce que le compteur est increments uniquement lorsqu'une 
operation appartenant a un groupe d'opSrations de types 
25 diffSrents est effectuee, le compteur n'etant pas 
increments pour les opSrations d'un type n 1 appartenant 
pas a ce groupe. 

5. Procede de transaction dans lequel les cartes 
sont rechargeables dans des terminaux de rechargement 

30 (10) disperses susceptibles de recevoir des donnSes 
d'un serveur (20), caracterise en ce qu'il comporte les 




2716021 



eNSpgCID: <FR 271 6021 A1 J_> 



2716021 

* ' ) 

19 

Stapes suivantes : 

- chargement, depuis le serveur vers les 
terminaux, de donnees permettant aux tenninaux de 
verifier le droit d'une carte a etre rechargee; 

- introduction d"une carte (40) dans un terminal 
de rechargement quelconque; 

- lecture par le terminal de donnees 
d ' identification de la carte (PIN); 

- lecture par le terminal du contenu (NBR) d'un 
compteur d' operations de rechargement (22) present dans 
la carte; 

- lecture et verification par le terminal d*un 
certificat d • authenticity (CRT) present dans la carte, 
ce certificat faisant intervenir les donnees 
d 1 identification de la carte et le contenu du compteur 
d 1 operations de rechargement, le compteur d f operations 
de rechargement (22) etant increments aprSs chaque 
operation de rechargement et n' etant pas increments 
pour des operations autres qu'un rechargement. 

6. Systeme de transaction comportant des cartes 
a mSmoire (40) et des terminaux (10) de rechargement de 
carte, caractSrise en ce qu'il comporte des moyens pour 
inscrire dans une zone (22) de memoire non volatile de 
la carte un nombre (NBR) representant le compte du 
nombre d' operations de rechargement effectuSes avec la 
carte, ce nombre etant increments irreversiblement a 
chaque operation de rechargement et n* etant pas 
increments pour d 1 autres opSrations effectuSes avec la 
carte . 

7. Systeme selon la revendication 6, caractSrisS 
en ce qu'il est prevu des moyens de verification de 
1 • habilitation de la carte, ces moyens faisant 
intervenir des donnSes d 1 identification (PIN) prSsentes 
dans la carte, et le contenu (NBR) de la zone de 
memoire ( Z2 ) . 

8. Systeme de gestion collective de nombreux 
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restaurants d'entreprise ayant chacun plusieurs 
terminaux de rechargement disperses a la disposition 
des employes de 1 • entreprise, caracterise en ce qu*il 
utilise le procede de transaction selon l'une des 
revendications 1 a 5. 
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